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ABSTRACT 


A  method  of  documenting  exception  propagation  and  handling  in  Ada  programs  is 
proposed  Exception  propagation  declaration*  are  introduced  as  a  new  component  of 
Ada  specifications.  Thi  permits  documentation  of  those  exceptions  that  can  be 
propagated  by  a  subprogram.  Exception  handlers  are  documented  by  entry  assertions. 
Axioms  and  proof  rules  for  Ada  exceptions  are  given.  These  rules  are  simple 
extensions  of  previous  rules  for  Pascal  and  define  an  axiomatic  semantics  of  Ada 
exceptions.  As  a  result,  Ada  programs  specified  according  to  the  method  can  be 
analysed  by  formal  proof  techniques  for  consistency  with  their  specifications,  even  if 
they  employ  exception  propagation  and  handling  to  achieve  required  results  (i.e.  non 
error  situations).  Example  verifications  are  given. 
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1.  Introduction 


Exception*  in  the  Ada  language  [l]are  intended  to  provide  a  facility  for 
dealing  with  erron  and  exceptional  situation!  arising  during  program  execution. 
An  exception  is  an  event  that  eauses  suspension  of  normal  program  execution  — 
called  raising  an  exception.  Actions  in  response  to  the  occurrence  of  an  exception 
are  coded  in  special  units  called  handlers.  When  an  exception  is  raised,  execu¬ 
tion  of  a  handler  replaces  execution  of  the  current  unit.  The  choice  of  handlers 
is  dynamic  —  i.e.,  determinable  only  at  runtime.  Ada  exceptions  are  clearly  a 
powerful  programming  facility  and  a  study  of  their  semantics  and  proof  is  needed. 

The  obvious  semantics  of  raising  an  exception  is  that  of  a  jump  to  the  cor¬ 
responding  handler.  In  fact,  the  conventional  go  to  ruie  [10,  ll]is  sufficient  to 
describe  exceptions  with  static  association  of  handlers.  Problems  arise  in  the  case 
where  an  exception  is  not  handled  locally  in  a  subprogram  and  the  association  of 
the  exception  with  the  handler  is  dynamic.  The  answer  lies  in  requiring  documen¬ 
tation  for  exceptions  that  are  propagated  by  procedures  or  functions;  it  is  then 
possible  to  modify  the  procedure  call  rule  to  describe  the  dynamic  association  of 
handlers  with  exceptions  at  call  time. 

We  propose  a  method  of  specifying  exceptions  in  Ada  programs.  Axioms  and 
proof  rules  based  on  these  specifications  are  given.  These  define  an  axiomatic 
semantics  of  Ada  exceptions,  and  make  possible  the  verification  (proof  of  consis¬ 
tency  with  specifications)  of  Ada  programs  containing  exceptions.  Our  specifica¬ 
tions  and  proof  rules  apply  to  programs  with  exceptions  irrespective  of  whether 
exceptions  are  used  only  for  error  situations  or  as  a  method  of  programming  nor¬ 
mal  program  behavior  (e.g.,  the  program  is  intended  to  continue  running  when 
exceptions  are  raised  and  handled).  The  proof  rules  are  simple  extensions  of  rules 
of  conventional  axiomatics  e.g.  those  of  Pascal  [7] .  Our  results  show  that  if  the 
programmer  follows  a  simple  specification  discipline,  then  the  use  of  exceptions  as 
a  normal  programming  tool  does  not  greatly  complicate  the  analysis  of  programs 
for  consistency  with  specifications. 

We  restrict  presentation  of  our  method  to  simple  cases.  In  particular,  the 
semantics  assumes  call  by  reference  implementation  for  out  and  in  out  parameters. 
Similar  proof  rules  can  be  given  for  other  implementations  of  parameter  passing. 
Extensions  to  more  complicated  programs,  e.g.  Ada  packages  or  Ada  programs 
in  which  exceptions  are  propagated  beyond  their  scope,  are  outlined  in  section  5 
and  the  appendix.  We  will  not  deal  with  the  task  failure  exception  propagated 
between  tasks  or  with  suppression  of  exceptions. 

Throughout  this  paper  we  will  use  the  notation  and  terminology  of  the  Ada 
report  [l] ,  except  in  logical  assertions,  where  we  use  a[t]  to  denote  the  t-th  ele¬ 
ment  of  array  a  to  improve  readability.  The  word  subprogram  will  be  used  for  a 


function  or  procedure. 

A  statement  of  the  form  assert  <  assertion  >  is  not  the  assert  statement 
of  Ada;  <  assertion  >  is  a  logical  assertion  and  Is  not  intended  to  be  executed. 
Logical  assertions  are  more  general  specification  statements  than  Ada  conditions, 
but  they  obey  the  normal  scope  rules:  all  free  variables  are  visible  program  vari¬ 
ables. 

2.  Specifying  Exceptions 

The  exception  facility  of  Ada  includes 

—  declarations  of  user  defined  exceptions 

—  a  raise  statement  that  causes  an  exception,  and 

—  the  definition  of  exception  handlers,  l.e.  code  that  is  to  be  executed  whenever 
a  particular  exception  is  raised. 

We  now  define  the  formal  documentation  that  has  to  be  provided  for  excep¬ 
tions, 

(1)  No  documentation  is  required  for  exception  declarations  and  raise  statements. 

(3)  For  each  exception  handler  the  programmer  will  be  required  to  provide  an 
assertion  that  is  to  be  true  whenever  one  of  the  exceptions  in  the  when  clause  is 
raised.  Following  Ada  we  will  use  the  syntax: 


exception.handler  ::= 

when  exception  {|  exception  } 

assert  assertion  =>  sequence.of.statements 

(3)  An  exception  that  is  raised  in  a  subprogram  and  is  not  handled  locally  is 
said  to  be  propagated  by  this  subprogram  ([l]  11.3.1).  We  introduce  an  excep¬ 
tion  propagation  declaration  and  require  that  each  exception  propagated  by  a 
subprogram  be  specified  in  the  subprogram's  propagation  declaration.  Analogous 
to  a  handler,  a  propagation  declaration  has  to  provide  an  assertion  that  is  to  be 
true  whenever  one  of  the  exceptions  in  the  propagate  clause  is  propagated. 

Prbpagation  declarations  are  placed  at  the  end  of  the  Ada  subprogram  specifi¬ 
cation  ([l]6.2).  We  consider  propagation  declarations  as  part  of  a  (to  be  defined) 
specification  language  for  Ada.  As  such,  they  are  of  the  same  nature  as  global, 
entry,  and  exit  specifications  for  procedures  and  functions  of  Pascal  Plus  [ll]. 
We  use  the  syntax: 
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propagatioD.declaration  ::  = 

propagate  exception  {|  exception  } 
aisert  anertion 


subject  to  the  normal  scope  rules.  Note,  that  a  call  to  a  procedure  that  propagates 
an  exception  is  a  statement  that  “can  raise  an  exception”.  We  restrict  such  calls 
to  the  scope  of  the  exception;  the  use  of  propagate  declarations  now  makes  this 
restriction  compiler  checkable.  In  section  5  we  show  how  these  specification  re* 
quirements  may  be  relaxed  by  use  of  the  others  clause.  The  appendix  contains  an 
example  of  how  our  specifications  will  require  modifications  of  an  Ada  program 
that  propagates  an  exception  out  of  the  scope  of  the  declaration  of  that  exception. 

In  a  scope  5  where  an  exception  E  can  be  raised  either  by  a  raise  statement 
or  a  subprogram  call  the  assertion  associated  with  E  in  this  scope  is  defined  as 
follows: 

—  If  S  is  a  block  with  a  handler  for  E  then  the  assertion  of  this  handler  is  the 
associated  assertion. 

—  If  S  is  a  block  without  a  handler  for  E  then  the  assertion  associated  with  E 
in  S  is  the  assertion  associated  with  E  in  the  scope  immediately  enclosing  S. 

—  If  5  is  a  subprogram,  then  the  assertion  of  the  propagation  declaration  for  E 
is  associated  with  E. 


Remark:  An  exception  has  an  associated  assertion  in  every  scope  where  it  can  be 
raised. 

For  example,  consider  the  following  program. 
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procedure  p(...) 

propagate  £  auert  A  U 
begin 
begin 

t  •  » 

raiee  E\  —  B  ii  aisociated  aaiertion 

•  •  • 

exception 

when  E  auert  B  =>  . . . ; 

end; 

begin 

•  •  • 

raiie  £;  —  A  it  associated  assertion 

«  »  • 
end 
end  p 


3.  Axiomatic  Semantics  of  Exceptions 


3.1.  Raising  Exceptions 

Wherever  the  statement  raise  £*  occurs,  the  above  specification  principles 
guarantee  that  there  is  an  assertion  A,-  associated  with  Ei  at  that  point.  The 
semantics  of  raise  £,-  is  described  by  the  raise  axiom: 


{At}  raise  £<  {false}. 


3.3.  Blocks 

The  rule  of  exceptions  given  below  requires  that  any  exception  handler  achieves 
the  exit  assertion  of  the  block  in  which  it  is  contained.  The  handler  may  assume 
the  truth  of  the  assertion  in  the  when  clause. 

Let  C  be  the  block 
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a 


begin 

So 

exception 

when  Ei  auert  A\  =>  S\ 

when ... 

e  e  e 

when  En  auert  An  =>  Sn 
end 

then  we  have  the  following  rule  of  exception* 

{P)  So  {Q)t  (Aj)  (Q)  ...{An}  S»  { Q } 

{ P )  C  {Q} 

3.3.  Procedure  call* 

Rule*  given  in  3.1  and  3.2  are  sufficient  to  describe  the  effect  of  exceptions 
handled  in  the  subprogram  in  which  they  are  raised.  We  now  propose  a  modified 
procedure  call  rule  that  describes  the  effect  of  an  exception  propagated  by  a  pro* 
cedure.  We  will  restrict  our  attention  to  procedures  only;  a  similar  treatment  for 
functions  is  immediate. 

Let  p  be  a  procedure  that  propagates  the  exceptions  E\. . .  £»  and  let  Ai. . .  An 
be  the  corresponding  assertions  in  the  propagate  declaration  of  p.  Let  Bj  be  the 
assertion  associated  with  Ej  in  the  calling  environment  according  to  the  principles 
in  2.  The  procedure  call  rule  will  require  that  Ay  -*•  By  tor  all  exceptions  £y 
propagated  by  p  with  proper  substitutions  tor  in  parameters  and  quantification 
for  out  and  in*out  parameters. 

The  procedure  call  rule  presented  below  is  taken  from  [9] ,  adapted  for  Ada 
and  exception  handling.  Let  p  be  a  procedure  with  ft,  fot  and  fta  being  the  formal 
in,  out,  and  In  out  parameters  of  p  respectively.  We  assume  that  the  correctness 
of  the  body  of  p  has  been  established  with  respect  to  the  input  condition  /(/<,  /*>) 
and  output  condition  0(ft,  f0,  /<o).  Let  a,-,  a0,  and  ato  be  the  corresponding  actual 
parameters  of  a  call  to  p,  then  this  call  is  described  by  the  rule: 

P  —  /(«<,  A*,)  A  Vo0,  ato .(0(ait  a„,  a <*)  -*■  Q) 

P  f(oii  °<o)  A  Voe,  aot  ate)  -*■  Bj) 

•  •  • 

P  -*•  /(o<,a<o)  A  Vo0,oto.(AB(oi,o0,«<0)  -»  Bn) 

{P}  p(or,o0,Ote){Q} 
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where  the  clause  P  -*>  /(o<,  olo)  A  Va0l  a<0.(  A y(o<,  a9,  o<0)  -*  5/)  has  to  be  proven 
for  each  propagated  exception  £y  with  propagate  assertion  A/  and  By  associated 
with  Ej  in  the  calling  environment.  Note  that  the  treatment  of  exceptions  is 
similar  to  that  of  the  normal  output  condition;  raising  exceptions  may  be  viewed 
as  just  another  exit  of  p. 

The  above  rule  assumes  p  to  be  a  restricted  procedure  without  any  global 
variables.  It  may  be  extended  to  provide  for  global  variables.  Furthermore,  we 
assume  an  implementation  of  procedure  calls  using  call  by  reference  for  out  and 
in  out  parameters.  Our  rules  can  be  adapted  for  other  procedure  call  mechanisms. 
Also,  other  procedure  call  rules  (e.g.  [2,5,7])  can  be  extended  to  include  the 
conditions  A<  -*  J5<. 

4.  Examples 


4.1. 

Consider  the.  procedure  search  with  in  parameters  a,  n,  and  x  and  out 
parameter  t  with  the  entry  assertion  true  and  the  exit  assertions  1  <£  *  <  n  A 
x  =  a[t'].  In  case  that  the  value  x  is  not  in  a,  search  will  raise  the  exception 
not  found.  For  this  exception  search  contains  a  propagation  with  the  assertion 
Vj'.(l  <t  j  ^  n -*  x  a[j\).  Altogether  we  have  the  procedure  declaration 

type  narray  is  array  (1.  .n)  of  integer, 

procedure  search(a\  in  narray;  n:  in  integer;  x :  in  integer ;  t:  out  integer) 

entry  true 

exit  l<i^nA*  =  o[«] 

propagate  not  found  assert  V;'.(l  <,  j  <*  n  -+  x  «[/])  is 

begin 

•  •  • 

raise  notfound; 

•  •  • 

end 

A  proof  of  the  body  of  scorch  may  use  the  axiom 

{V;'.(l  <  <,  n  -»  x  o[;])}  raise  notfound  {false} 

Procedure  search  could  be  used  in  the  following  context  (m,  y,  and  6  are 
declared  in  some  global  scope): 
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assert  true] 
begin 

search(b,  m,  y,  k)\ 
exception 

when  notfound  auert  V/.(l  ^  ;  ^  m  -♦  y  5^  *uJ)  —> 

Jfc:  =  0 

end; 

auert  {y  =  fr[k]  V  ^V;.(l  £  j  £  V  *[j])  A  *  =  oj} 

Consistency  of  this  block  with  its  specifications  can  be  shown  by 

Vk^(l  <  *  £  mAy  =  *[*])-► 

y  =  b[k]  V  (Vj.(l  £  j  ^  m  -*•  y  5*  *M)  A  *  =  ojj  (1) 

vjt(vy.(i  <j<m-*yi* *[;']) -*  vy.(i  6[y]))  (2) 

Vj.(l  <;<m-y  5* 

y  =  6[0]  V (v/.(l  <  ;  £  m  -►  y  / *D*]) A 0  =  o)  {3) 

Formula  (1)  proves  that  the  exit  assertion  of  the  call  to  search  implies  the 
exit  assertion  of  the  block  (note,  that  P  and  I  of  the  procedure  call  rule  are  both 
true).  This  proves  consistency  if  the  call  to  search  terminates  normally. 

Formula  (2)  proves  that  the  assertion  associated  with  notfound  inside  search 
implies  the  assertion  associated  with  notfound  in  the  calling  environment  (see 
call  rule).  This  proves  that  notfound  is  propagated  by  the  call  to  search  only  in 
situations  that  the  handler  "expects”. 

Finally,  (3)  proves  that  the  handler  does  indeed  establish  the  exit  condition 
of  the  block  (i.e.  the  handler  "handles”  correctly). 

4.2. 

The  methods  presented  in  this  paper  are  also  useful  in  proving  that  an  ex¬ 
ception  will  never  be  raised.  If  we  have  an  exception  associated  with  the  assertion 
false,  then  the  corresponding  handier  will  never  be  executed  since  its  precondition 
is  never  satisfied.  Consider  the  example: 


••left  3j.l  =  b[j]; 

begin 

seareh(b,  m,  y,  k); 
exception 

when  not  found  inert  false  =>  <  empty  > 

end; 

inert  {y  =  6[ib]  } 

The  corresponding  verification  condition*  ire  (numbering  i*  in  previous  ex¬ 
ample): 

3/.(l  <3  <  mAy  =  &[;]) -* 

V*.((l  £  k  £  »Aff  =  »[*])-*  If  «*M)  (1) 

3y.(l  <  j  £  m  A y  =  &[;])  -*•  VJfc.(V;.(l  <r  j  <m->  y  *[;])  -*•  false)  (2) 
false  -*  y  =  6  [lb]  (3) 


5.  Extensions 

5.1.  Use  of  the  "others”  eonstruet 

Our  method  also  applies  if  an  exception  handler  contains  the  others  clause. 
If  a  block  contains  such  a  handler, 

exception 

•  •  • 

when  others  assert  A  =>  . . . 

then  in  this  block  A  is  the  assertion  associated  with  all  exceptions  that  are  raised 
in  the  block  and  are  not  contained  in  another  when  clause  in  the  handler.  All 
proof  rules  and  the  raise  axiom  apply  unchanged. 

The  situation  is  different  in  propagate  declarations.  If  we  allow  an  others 
clause  in  propagate  declarations  then  any  exception  that  is  not  explicitly  men¬ 
tioned  in  this  propagate  assertion  can  potentially  be  propagated  via  the  others 
clause.  Our  method  can  be  extended  to  handle  this  case  if  we  accept  a  more 
complicated  procedure  call  rule. 

The  general  principle  of  the  call  rule  remains  the  same:  for  each  exception 
that  can  potentially  be  propagated  by  the  called  procedure  we  have  to  prove  that 
the  assertion  specified  for  this  exception  in  the  propagate  declaration  implies  the 
assertion  associated  with  the  exception  in  the  calling  environment. 
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First,  note  that  a  scope  containing  a  call  to  a  procedure  with  an  others  clause 
in  the  propagation  delcaration  must  define  an  associated  assertion  for  every  ex¬ 
ception  that  may  be  raised  in  it;  thus  in  general  its  handler  or  propagate  declara¬ 
tion  also  has  to  have  an  others  clause.  Given  the  above  situation  we  can  classify 
all  exceptions  as  follows. 

50  —  set  of  exceptions  explicitly  named  in  handlers  of  propagate  declarations 
for  calling  environment. 

51  —  set  of  exceptions  explicitly  named  in  propagate  declaration  for  called  pro¬ 
cedure. 

Bj  —  associated  assertion  for  each  Ej  G  S0. 

Aj  —  assertion  specified  in  propagate  declaration  for  each  Ej  €  Si. 

Bqo  —  assertion  for  others  clause  in  handler  (or  propagate  declaration)  of  calling 
environment. 

Ago  —  assertion  for  others  clause  in  propagate  declaration  of  called  procedure. 
To  prove  that  a  procedure  call  is  correct  we  have  to  verify  that: 

a. )  Aj  -*  Bj  for  all  Ej  €  Si  fj  S0, 

b. )  Aj  -+  Boo  for  all  Ej  £  S{  —  Sot 

e.)  Ago  -*  Bj  for  ail  Ej  £  S0  —  Si,  and 
d.)  Aoo  Bgo. 

The  procedure  call  rule  has  to  be  augmented  by  these  cases,  where  proper 
substitutions  have  to  be  preformed  as  described  in  section  3. 

A  better  proposal  to  reduce  the  number  of  necessary  propagate  declarations 
is  to  introduce  a  single  global  exception,  error.  If  a  user  does  not  want  to  in¬ 
clude  each  propagated  exception  with  a  corresponding  assertion  in  a  propagate 
declaration  he  may  include  the  handler 

exception 

when  others  assert  A  =>  raise  error; 

in  any  subprogram  and  provide  a  propagate  declaration  for  error.  This  conver¬ 
sion  has  been  discussed  in  12.5.  of  the  Ada  rational  but  was  rejected  on  efficiency 
considerations. 

5.2.  Application  to  Packages 

The  method  described  in  this  paper  is  also  applicable  to  exceptions  propagated 
from  within  modules  (or  Ada  packages).  It  applies  directly  to  calls  of  module 
procedures  but  requires  some  changes  when  applied  to  module  bodies.  Let  us 


briefly  outline  the  key  idea  without  going  into  the  details  of  a  particular  method 
of  specification  and  verification  of  modules. 

Let  us  assume  that  to  the  using  program  a  module  represents  an  abstract 
object  together  with  certain  operations  (module  procedures).  Some  of  these  may 
propagate  exceptions,  overflow  in  a  stack  for  instance.  Part  of  the  visible  specifi¬ 
cation  of  module  procedures  are  exception  propagation  declarations  using  abstract 
specifications.  Then  the  procedure  call  rule  of  section  3.3  applies  to  module  pro¬ 
cedure  calls  as  well. 

For  example,  the  package  in  [l]  12.3,  could  be  specified  as 

generic  (size:  integer;  type  elem) 
package  stack  is 

overflow,  underflow :  exception; 
procedure  pu$h(E :  in  elem) 

propagate  overflow  assert  full(stack); 
procedure  pop(E:  out  elem) 

propagate  underflow  assert  empty(stack); 
end  stack 

This  additional  documentation  is  valuable  to  the  programmer  even  if  a  formal 
verification  is  not  attempted.  The  Ada  syntax  merely  states  that  any  of  the 
module  procedures  may  raise  any  one  of  the  listed  exceptions.  The  propagate 
declarations  give  the  extra  information  that,  for  example,  pop  will  never  raise  the 
exception  overflow. 

The  extra  problem  comes  in  verifying  that  exceptions  are  raised  correctly  in 
the  stack  body.  Internal  assertions  associated  with  exceptions  may  refer  to  local 
variables  of  the  module  body  in  addition  to  parameters  of  procedures.  Thus  the 
condition  / ull(stack)  may  internally  correspond  to  a  condition  length  =  size  for 
some  variable  length  local  to  the  module  body.  Consequently,  for  overflow  the 
following  raise  axiom  is  valid  within  the  stack  body: 

{length  =  size)  raise  overflow  {false}. 

A  "module  declaration  rule”  has  to  enforce  that  the  visible  propagate  asser¬ 
tion  for  an  exception  is  equivalent  to  the  assertion  in  the  body  that  describes  the 
internal  state  in  which  the  exception  is  propagated. 

5.3.  Predefined  exceptions 

It  is  conceivable  that  predefined  exceptions  can  be  handled  with  our  method. 
The  situation  here  is  complicated  by  the  fact  that  predefined  exceptions  are 
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usually  raised  implicitly  by  numerous  different  statements  and  expressions.  There* 
fore,  all  proof  rules  have  to  be  changed  to  account  for  exceptions.  For  example, 
the  assignment  z  «—  y/z  in  a  scope  where  A  is  the  assertion  associated  with 
divide.error  is  not  described  by  the  standard  assignment  axiom  {P  \yj)z 
y/z{P }  but  rather  by  the  rule 


{<?}  * «-  vf *  {P} 

This  rule  differs  from  the  standard  assignment  axiom  in  having  an  extra 
premiss  requiring  proof  that  the  associated  assertion,  A,  is  true  when  divide. err  or 
is  raised.  Similar  extra  premisses  must  be  added  to  the  proof  rules  for  many 
other  language  constructs  leading  to  an  exponential  increase  in  the  number  of 
subproblems  such  as  Q  A  z  —  0  -♦  A.  If,  however,  A  is  the  assertion  true,  then 
the  additional  subproblems  are  trivial.  In  many  cases  associating  true  with  an 
exception  handler  will  be  sufficient  to  verify  that  a  program  continues  correctly 
after  an  exception  has  been  raised. 

Since  predefined  exceptions  frequently  correspond  to  "runtime  errors",  an  al¬ 
ternate  approach  towards  predefined  exceptions  is  to  verify  that  for  certain  sets  of 
input  values  these  exceptions  will  never  be  raised.  Positive  results  in  this  direction 
are  reported  in  [4] . 

ft.  Conclusion 


We  have  given  an  axiomatic  semantics  for  Ada  exceptions  based  on  a  method 
of  formally  specifying  exceptions;  the  method  extends  to  packages  in  a  natural 
way.  The  required  documentation  appears  very  natural  and  should  not  be  too 
demanding  for  the  programmer.  The  propagation  declaration  is  a  helpful  specifi¬ 
cation  even  in  cases  where  a  formal  verification  is  not  desired  as  is  shown  by  the 
documentation  of  the  stack  module  in  5.1.  The  additional  information  provided 
by  propagate  declarations  can  be  used  to  check  for  certain  semantic  restrictions 
at  compile  time,  e.g.  to  check  that  no  exception  is  propagated  out  of  its  scope,  or 
that  all  exceptions  that  may  be  raised  within  a  subprogram  and  not  propagated 
are  handled  within  that  subprogram. 

The  question  of  how  the  task  failure  exception  can  be  treated  in  a  multi  task 
program  and  whether  this  can  be  done  consistently  with  our  method  has  to  be 
investigated  in  future  research. 
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Appendix 


Propagating  exception*  out  of  their  scope 

The  Ada  rationale  [l]  gives  the  following  example  of  exceptions  propagated 
out  of  their  scope  (12.5.2): 


package  D  Is 
procedure  A; 
procedure  B\ 
end 


procedure  Outside  is 
begin 


end 


—  Outside  is  declared  outside  the  scope 
of  error 

—  D.A  may  propagate  error  in  which  case  Outside 
will  propagate  "something”  that  cannot  be 
named  syntactically  in  the  declaration  of  Outside 


package  body  D  Is 

error:  exception;  —  scope  of  error-exception 

procedure  A  is 

begin 

. . .  raise  error, 

end; 


procedure  B  is 
begin 

•  •  0 

Outside ;  —  call  to  Outside  may  propagate  "something”  which 

...  the  Ada  implementation  will  recognize  as  error 

exception 

when  error  =>  ... 

end; 
end  D 

In  this  example  the  scope  of  the  exception  error  is  the  body  of  D.  The 
call  D.A  in  outside  may  propagate  error  and  cause  error  to  be  propagated  from 
Outside.  Since  Outside  is  declared  outside  the  scope  of  error,  this  exception 
cannot  be  named  explicitly  in  a  handler  for  Outside.  It  can  be  handled  only  by 


\ 
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an  others  clause.  The  programmer  has  essentially  lost  the  ability  to  distinguish 
error  from  other  exceptions  and  to  handle  It  distinctly.  In  programs,  exceptions 
propagated  out  of  their  scope  become  anonymous.  Interestingly,  the  Ada  im¬ 
plementation  will  maintain  the  identity  of  error  when  it  is  propagated  outside 
its  scope.  Therefore,  if  it  is  propagated  back  into  its  scope  again  —  as  in  this  ex¬ 
ample  when  Outside  is  called  from  B  —  it  will  be  handled  by  a  handler  tor  error 
and  not  by  others.  The  implementation  thus  behaves  as  though  all  exception 
propagations  are  within  the  scope  of  the  exception. 

If  Ada  is  extended  to  require  propagate  declarations  (without  an  others 
clause),  propagation  of  exceptions  beyond  their  scope  is  syntactically  illegal.  For 
example  the  package  D  must  be  modified.  Since  A  can  propagate  error  and  A 
is  a  visible  procedure  of  D,  the  exception  error  has  to  be  declared  in  the  visible 
part  of  D.  Then  the  exception,  D.error,  is  visible  to  all  scopes  which  can  call 
D.A.  Using  our  documentation,  the  above  example  could  be  written  as: 


package  D  is 

error:  exception; 
procedure  A 

propagate  error  assert 
procedure  B; 


end 


—  D.error  exception  declaration 
—  all  calls  to  D.A  are  within  the  scop<v»f 
P ;  D.error 


procedure  Outside 

propagate  D.error  assert  Q 
Is 

begin 

Q  is  the  assertion  associated  with  D.error 
a  handler  for  D.error  could  also  be 
included  in  outside 


D.A’, 


end 


If  one  chooses  to  allow  others  clauses  in  propagate  declarations  as  indicated 
in  section  5,  then  propagation  of  exceptions  out  of  their  scope  becomes  possible. 
In  this  case  our  method  will  work  correctly  according  to  the  Ada  semantics. 
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Proof  of  flic  transfer  example 


We  consider  a  slightly  modified  version  of  the  file  transfer  example  given 
in  the  Ada  rationale  in  12.3.3.  In  addition  to  propagate  and  handler  assertions, 
the  program  is  documented  with  entry,  exit,  initial,  and  invariant  assertions  as 
introduced  for  Pascal  Plus  in  [ll]. 

We  assume  that  the  system  routines  get  and  put  have  the  following  specifi¬ 
cations: 

generie(type  t) 

procedure  get(f:  in  out  file  of  t;  z:  out  t) 

Initial  /  =  /0 
entry  true 

exit  -i empty(fO)  A  /0  =  append(li»t(x),  f) 
propagate  end^of.file  assert  empty(f  0)  A  /  =  / 0; 

generie(type  t) 

procedure  put(/:in  out  file  of  t;  xi  in  t) 
initial  /  =  /0 
entry  true 

exit  /  =  append(f0,  li»t(x))] 

We  prove  the  correctness  of  the  following  transfer  procedure;  get  and  put  are 
assumed  to  be  appropriate  instances  of  the  generic  procedures  declared  above: 

procedure  tran$fer(infi  in  out  file  of  t;outf :  out  file  of  t) 
initial  inf  =  sn/0 
entry  empty[outf) 
exit  outf  =  infO 

is 

e:t; 

begin 

invariant  append(outf,inf)  =  in/0 

loop 

get(inf,e); 
put(outf,c) 
end  loop; 
exception 

when  end.of.file  assert  empty(in/)  A  out/  s=  sn/0  =>; 

end; 

The  correctness  is  established  by  proving  the  following  verification  conditions. 
Note,  that  instead  of  introducing  universal  quantifiers  we  use  new  variables  to 
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construct  formulas  logically  equivalent  to  the  quantified  formulas  in  the  procedure 
call  rule. 

1)  Correctness  of  the  handler:  The  handier  code  (empty  statement)  has  to  achieve 
the  exit  condition  of  the  block: 

(empty  (in/)  A  outf  =  in/0  -♦  out/  =  in/0) 

This  verification  condition  is  trivially  true. 

2)  Correctness  of  raising  the  exception:  The  propagate  assertion  for  end.of.file 
in  get  must  imply  the  handler  assertion.  Since  get  is  called  within  the  loop,  it 
may  be  assumed  that  the  loop  invariant  is  true  when  a  propagation  occurs;  the 
verification  condition  has  the  form 


invariant  A  propagate  assertion  — *■  handler  assertion : 

tn/_0  is  a  new  variable  denoting  the  value  of  the  actual  parameter  inf  of  the  call 
to  get  when  propagation  occurs. 

(append(outf,  inf)  a:  in/0  A  inf  =  in/. 0  A  empty(inf) 

— ► 

empty(inf.  0)  A  otttf  =  in/0) 

This  verification  condition  simplifies  to  true,  observing  that  append(outf,  inf)  as 
outf  whenever  empty[inf). 

3)  Correctness  of  entering  and  leaving  the  loop:  The  entry  condition  of  proce¬ 
dure  transfer  must  imply  the  loop  invariant;  when  the  loop  terminates  the  loop 
invariant  and  the  negation  of  the  loop  test  (- »true )  must  imply  the  exit  condition 
of  transfer.  outf.O,  inf. 0  are  new  variables  denoting  the  final  values  of  outf 
and  inf  on  exit  from  the  loop. 

(inf  =  in/0  A 
empty(outf) 


append(outf,  inf)  =  inf  0  A 
(append(outf.  0,  inf.  0)  =  in/0  A 
-rtrue 


outf.  0  =  in/0)) 

Propositional  reasoning  reduces  this  condition  to 

(in/  =  in/0  A  empty(outf)  -*  append(outf,infO)  =  in/0) 
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which  can  be  teen  to  be  true  by  properties  of  append. 

4)  Correctness  of  loop:  The  loop  invariant  mutt  be  preserved  by  executing  the 
loop  body: 

( append(outf ,  inf )  =  in/0  A 
-iempty[inf)  A 

inf  =  appcnd[list(c-Q)tinf  A)  A 
outfA  =  append(outf,  /ist(c.O)) 

— ► 

append(out/„l,i»/_l)  =  in/0) 

After  some  substitutions  this  becomes 

append[outf,  append(li»t(c.O),  inf  A))  =  in/0 
— ► 

append(append(ovtf,  /tit(c.O)),  inf  A)  as  in/0 
which  is  true  by  associativity  of  append. 


